Check weblog permission in XML-RPC Blogger/MetaWeblog handlers - #164
Check weblog permission in XML-RPC Blogger/MetaWeblog handlers#164snoopdave wants to merge 3 commits into
Conversation
A caller without POST permission now scans at most a fixed number of entries rather than the whole weblog before the in-memory permission filter runs, and a non-positive count returns nothing. Claude-Session: https://claude.ai/code/session_01A1fhY1E2PCFU6UAPXu2WtV
There was a problem hiding this comment.
Reviewed with the multi-agent find-and-verify pass. The direction is right and the per-method permission matrix is a real improvement over the old membership-only check. Three things look like regressions rather than intended tightening, so I'm holding approval on those (inline: the Weblog.active gate, the DRAFT_SCAN_CAP arithmetic, and the unwrapped lookup in validateWeblog). Three more are behavior changes that may well be intended but aren't in the description, so they're inline as questions: getPost now requiring write permission, INVALID_POSTID for a missing POST permission on the caller's own entry, and Blogger getRecentPosts honoring numposts. Two small cleanup notes at the end. Happy to approve once the first three are settled.
| private boolean isWeblogAvailable(Weblog website) { | ||
| return website != null | ||
| && Boolean.TRUE.equals(website.getVisible()) | ||
| && Boolean.TRUE.equals(website.getActive()); |
There was a problem hiding this comment.
Weblog.active isn't a disabled flag: per its javadoc (and ROL-485) it's the user-settable "include in front page / planet listings" toggle, and the web UI never blocks editing an inactive weblog. Gating here means an owner who unticks Active in Weblog Settings to hide the blog from the front page loses every XML-RPC call for it (newPost, editPost, getRecentPosts, and via getEntryForWrite even deletePost by id) with "not found or disabled". The pre-PR check was visible only, which is the flag that means what this code wants.
| if (weblog.hasUserPermission(user, WeblogPermission.POST)) { | ||
| wesc.setMaxResults(numposts); | ||
| } else { | ||
| wesc.setMaxResults(Math.max(numposts, DRAFT_SCAN_CAP)); |
There was a problem hiding this comment.
Math.max(numposts, DRAFT_SCAN_CAP) makes the cap a floor, not a ceiling: numposts=1000000 scans a million rows, and for a normal numposts a limited member only ever sees drafts that fall within the 200 most recent entries. With more than 200 published entries newer than their draft, getRecentPosts returns an empty list even though getPost on the draft's id succeeds. Same shape at MetaWeblogAPIHandler.java:445. Math.min is what the javadoc describes, and the drafts case probably needs a status-aware query rather than a scan of everything.
| protected Weblog validateWeblog(String blogid, User user, | ||
| String requiredAction) throws Exception { | ||
| WeblogManager weblogMgr = WebloggerFactory.getWeblogger().getWeblogManager(); | ||
| Weblog website = weblogMgr.getWeblogByHandle(blogid); |
There was a problem hiding this comment.
The deleted validate() wrapped the user and weblog lookups in a try/catch that logged and converted backend failures into an authorization fault. Here getWeblogByHandle runs outside any try, so a WebloggerException (transient DB trouble, say) escapes as a raw exception and the XML-RPC servlet returns a generic server fault carrying the internal message. Easy to trigger in tests with a hyphenated blogid. Worth restoring the wrap.
| } | ||
| validate(entry.getWebsite().getHandle(), userid, password); | ||
| User user = validateUser(userid, password); | ||
| WeblogEntry entry = validateEntry(postid, user, null); |
There was a problem hiding this comment.
Intended? getPost used to require only weblog membership; validateEntry(postid, user, null) now requires entry.hasWritePermissions(user), which is false for EDIT_DRAFT members on published entries. So a limited member can no longer read, via the API, a published entry that the site serves publicly, and their client reports the post as missing. The new test at XMLRPCWeblogPermissionTest.java:282 locks this in, so if it's not deliberate it's worth catching before it becomes the contract.
| String additionalAction) throws Exception { | ||
| WeblogEntry entry = getEntryForWrite(postid, user, additionalAction); | ||
| if (entry == null) { | ||
| throw new XmlRpcException(INVALID_POSTID, INVALID_POSTID_MSG); |
There was a problem hiding this comment.
I read the description's "foreign and unknown identifiers produce the same fault" as deliberate anti-enumeration, which makes sense for entries the caller can't see. This also covers the case where the caller can see and edit the entry and only lacks POST: a limited member who just saved a draft with publish=false retries with publish=true and gets INVALID_POSTID for the id that worked seconds ago. Clients that treat that fault as "deleted on the server" will drop or re-create the post. For an entry the caller already has access to, a not-authorized fault leaks nothing and is far kinder.
|
|
||
| try { | ||
| Vector<Object> results = new Vector<>(); | ||
| if (numposts <= 0) { |
There was a problem hiding this comment.
Intended? The old Blogger getRecentPosts ignored numposts and returned everything; this returns an empty list for numposts <= 0 and truncates otherwise. Honoring numposts is arguably the correct behavior, but it's a silent contract change for Blogger 1.0 clients and export scripts that relied on the old one, so it deserves a line in the description at least. Returning everything for numposts <= 0 (rather than nothing) would keep the old tooling working.
| throw new XmlRpcException(WEBLOG_NOT_FOUND, WEBLOG_NOT_FOUND_MSG); | ||
| } | ||
| if ( !apiEnabled ) { | ||
| if (!Boolean.TRUE.equals(website.getEnableBloggerApi())) { |
There was a problem hiding this comment.
Small one: the enableBloggerApi check lives here and again in getEntryForWrite (line 197), and the two paths report it differently (BLOGGERAPI_DISABLED here, collapsed into INVALID_POSTID there). Doing it once in isWeblogAvailable would keep the faults consistent.
| @@ -82,7 +83,8 @@ public Object getCategories(String blogid, String userid, String password) | |||
| mLogger.debug(" BlogId: " + blogid); | |||
There was a problem hiding this comment.
Consistency note rather than a defect: XML-RPC now grants EDIT_DRAFT members read access (getCategories, getRecentPosts, getPost) while RollerAtomHandler.canView/canEdit requires POST on the same weblog. Whichever is right, the two remote APIs probably want the same answer, and the Atom one is the older reference.
2 participants
The Blogger and MetaWeblog XML-RPC handlers are Roller's legacy remote-publishing
API. This change makes them apply the same per-weblog and per-entry permission
model that the rest of Roller uses, so a caller is authorized against the weblog
or entry an operation actually touches.
What changed
ADMIN/EDIT_DRAFT/POST, or entry-level write permission) to the weblog or entry actuallytouched.
getUserInforeturns only the authenticated user;getUsersBlogsreturns onlyAPI-enabled member weblogs.
Tests
Table-driven integration suite over every exposed handler method: authorized
member, authenticated non-member, insufficient role, disabled user/weblog/API,
draft-to-published transition, filtered recent posts, category/weblog mismatch,
and foreign/absent resource identifiers.